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(54) Dynamic extension of static device drivers 

(57) A method of changing the functionality of a stat- 
ically bound device driver, by dynamk:ally extending the 
static device driver using a registered driver extension. 
The static device driver has a plurality of handlers or 
functions (such as input/output functions) used to con- 
trol a device that is connected to or part of the computer 
system, and the driver extension modifies at least one 



of these functions, although it can be used to change 
several, or even all, of the functions. In the embodiment 
wherein the computer system is a UNIX-type worksta- 
tion having a kernel residing in the memory, the static 
device driver is baded In the kernel and is dynamically 
extended by providing at least one entry point for the 
driver extension. 
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Description 

Technical Field of the Invention 

The present invention generally relates to computer 
systems and more particularly to a method for extending 
static device driver functionality without requiring re- 
building of the operating system. 

Background of the Invention 

The basic structure of a conventional computer sys- 
tem 1 0 is shown in Figure 1 . The heart of computer sys- 
tem 10 is a central-processing unit (CPU) or processor 
12. which is connected to several peripheral devices, 
including input/output (I/O) devices 14 (such as a dis- 
play monitor and keyboard) for the user interface, a per- 
manent memory device 1 6 (such as a hard disk or floppy 
diskette) for storing the computer's operating system 
and user programs, and a temporary memory device 18 
(such as random^ccess memory or I^M) that is used 
by processor 12 to carry out program instructions. Proc- 
essor 12 communicates with the peripheral devices by 
various means, including a bus 20 or a direct channel 
22. Computer system 10 may have many additkxial 
components which are not shown, such as serial and 
parallel ports for connectkxi to, e.g., modems or print- 
ers. TTiose skilled in the art will further appreciate that 
there are other components that might be used in con- 
junction with those shown in the block diagram of Figure 
1 ; for example, a display adapter connected to proces- 
sor 12 might be used to control a video display monitor, 
various types of devk;e drivers (software programs) are 
used to control the hardware devices. 

Computer system 10 also includes firmware 24 
whose primary purpose is to seek out and load an op- 
erating system from one of the peripherals (usually per- 
manent memory device 16) whenever the computer is 
first tumed on. The process of seeking out and loading 
the operating system is referred to as "booting" the com- 
puter. Computer system 10 may be designed to allow 
firmware 24 to re-initialize an operating system without 
turning the computer off and back on again (a "soft" 
boot). Firmware 24 is essentially a series of machine 
instructk)ns which are typically stored in a read-only 
storage (ROS) device, such as read-only memory 
(ROM). As shown in the flow chart of Figure 2, after 
power to computer system 10 is turned on, processor 
12 begins to execute the firmware instructions and 
seeks out an operating system (26). If an operating sys- 
tem is found, it is toaded (28) into temporary memory 
18, including any device drivers present in the operating 
system image, to enable the system to communicate 
with appropriate hardware. Thereafter, additbnal device 
drivers may be dynamk:ally loaded by the operating sys- 
tem (30), for example, if a hardware device is connected 
to the computer system after the boot sequence. Finally, 
the operating system altows other application layers to 



be added, i.e., user software programs (32). 

The foregoing descriptksn generally applies to any 
type of operating system, including two popular operat- 
ing systems known as MSDOS and UNIX (MSDOS Is a 

5 trademark of Mk^rosoft Corp.; UNIX Is a trademark li- 
censed exclusively by X/Open Company Ltd.), but the 
present invention has partk:ular application to UNIX. 
UNIX is a multi-user, multi-tasking operating system 
which is available from a variety of sources with different 

10 versions. These include, anrxxig others. System V from 
AT & T, AIX from IBM (AIX is a trademark of Intematonal 
Business Machines Corporatk>n) and Mach from NeXT 
Computers. Figure 3 illustrates a typk^al UNIX worksta- 
tion 34. Workstatkxi 34 includes the varnus hardware 

IS components shown in Figure 1. and generally repre- 
sented at 36. and f urthemrwre includes two software lay- 
ers, the kernel 38 and the user applicatkxi layer 40. Ker- 
nel 36 is the towest level of the operating system and 
acts as the intermediary between user programs and 

20 hardware devk:es and includes, anrxxig other things, de- 
vtee drivers that interlace with hardware control 42. Ker- 
nel 38 may Include static devrce drivers 44 which are 
originally bound with the kernel during initialization and 
dynamically k>aded device drivers 46 which are added 

25 to the kemel after initialization. A dynamk:ally loaded de- 
vrce driver 46 can be used for a unk^ue devce or can 
simply be a replacement for a generic statte devce driv- 
er. Both types of devce drivers are usually accessed by 
a buffering mechanism such as a devfce switch table 48. 

30 Device drivers are often hardware dependent, 
which can present difficulties when installing or using 
particular hardware devfces. If an appropriate devk;e 
driver for a new device Is not already present in the ker- 
nel, (i.e., statk:ally bound) and if a dynamically kjadable 

35 driver is not available, then the kemel must be re-bound 
with a new static device driver. If a dynamk:alty loadable 
driver is available, then it can easily be k>aded as a ker- 
nel extension but, in some cases, the system requires 
certain devrces or hardware functions to be provkjed on- 

40 ly via static device drivers bound in the kemel since the 
facilities they require must exist prior to the ability to \oa6 
kernel extensions. These functions include, for exam- 
ple. NVRAM, RAMDD, and console device drivers. In 
these cases, the only way to enhance the functionality 

45 or capabilities of the static device driver is to rebuild the 
base kemel. Similarly, there is no way to modify a statk: 
device driver once it has been baded. For example, 
there might be a bug (software instmction enor) in the 
static device driver, but it cannot be fixed unless the ker- 

50 nel is rebuilt. It would, therefore, be desirable and ad- 
vantageous to devise a method of changing the func- 
tionality of a statically bound device driver without re- 
quiring rebuilding of the kemel or otherwise rebooting 
the operating system. 

55 

Disclosure of the Invention 

According to the present invention, there is provid- 
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ed a method for providing control of a device in a com- 
puter system having memory, comprising the steps of: 
loading a static device driver into the memory of the 
computer system, the static device driver having means 
for providing a plurality of functions used to control the s 
device; the method being characterised by the further 
step of: dynamically extending the static device driver 
using a driver extension. 

According to another aspect of the invention, there 
is provided a computer system comprising: a hardware 10 
device; memory means storing a static device driver 
used to control said hardware device; processor means 
for carrying out instructions from said static device driver 
to control said hardware device; characterised in that 
the system further comprises: a device driver extension is 
registered with said static device driver such that a func- 
tion call issued to said hardware device is rerouted by 
said static device driver to said device driver extension. 

Thus, the invention provides an improved method 
of loading device drivers for a computer system which 20 
allows modification of a statically bound device driver 
without requiring rebuilding of the operating system. 

The preferred method provides control of a device 
in a computer system, generally comprising the steps of 
loading a static devk:e driver into the memory of the 25 
computer system, and thereafter dynamically extending 
the static device driver using a driver extension which is 
registered with the static device driver. The static device 
driver has a plurality of handlers or functions (such as 
input/output functions) used to control the device, and 50 
the driver extension modifies at least one of these func- 
tions, although it can be used to change several, or even 
all. of the functions. In the pref en-ed embodiment where- 
in the computer system is a UNIX-type workstation hav- 
ing a kernel residing in the memory, the static device 35 
driver is within the kernel and is dynamically extended 
by providing at least one entry point for the driver exten- 
sion. 

Brief Description of the Drawings ^0 

The invention will now be described with reference 
to a preferred embodiment thereof, as illustrated in the 
accompanying drawings, wherein: 

45 

Figure 1 is a block diagram of a prrar-art computer- 
operating system; 

Figure 2 is a flow chart illustrating how a computer 
loads a prior-art operating system with static device so 
drivers bound to the operating system, and then 
loads dynamically loadable device drivers after 
loading the operating system; 

Figure 3 is a block diagram of a prk)r art UNIX-type ss 
workstation having static and dynamrc device driv- 
ers; 



Figure 4 is a bkxk diagram of a UNIX-type work- 
statton configured according to the present inven- 
tion with registered driver extensbns; and 

Figure 5 is a flow chart illustrating how. according 
to the present invention, a computer loads an oper- 
ating system with static device drivers that allow 
registration of driver extenskxis, and how the statk: 
drivers dynamk^ally access the registered exten- 
sbns. 

Detaiied Description of the Invention 

With reference now to the figures, and in particular 
with reference to Figure 4, there is depicted one em- 
bodiment 50 of a UNIX-type woricstation according to 
the present inventbn. Workstation 50 Is generally com- 
prised of the same basic hardware as shown in Figure 
1 , portions of which are indicated at 52. but workstatbn 
50 has a novel operating system loaded in kemel 54 
which allows for registratkxi of static device-driver ex- 
tensbns. Kernel 54 has the static device drivers 56 
bound thereto, and includes conventional hardware 
control 58 that is connected to the outputs of the devrce 
drivers. Static device drivers 56 are accessed via a con- 
ventk)nalKJe vice switch table 60 that acts as an interface 
with the user applications 62. Kemel 54 also includes 
driver extensbns 64 that are "registered" with statb de- 
vice drivers 56. The driver extensbns provbe control for 
hardware control 58, but are not accessed by the device 
switch table. Instead, static device drivers 56 register 
specific handlers or functbns (like open, read, iocti, or 
other I/O control functbns) to provkJe process entry 
points for those functbns with respect to the particular 
devbe being accessed. 

This solutbn albws the functionality of a statb de- 
vbe driver to be dynambally extended in order to get 
the flexibility of a badable device driver in cases where 
static boot-time functionality Is also required. One such 
example is that, at a later point during system initializa- 
tion, a kernel extension couW register Its own ioctl() han- 
dler to be called in response to an ioctl() call to that static 
device driver. This example could also be expanded to 
other device-driver entry points. In this manner, a user 
can change the functkwi of a device driver that is stati- 
cally bound without rebinding the kemel. This adapta- 
bility allows a user to enhance a device driver, e.g., pro- 
vkJe hardware-specific differentiators, or to otherwise 
modify the driver, e.g.. fix a bug. 

The typbai operatbn of a computer system using 
registered device extensbns Is shown in Figure 5. After 
power to the system is turned on (or a soft-boot com- 
nrrand Is executed), the firmware searches for an oper- 
ating system to load (70), The operating system is then 
baded into primary memory, including any statb devbe 
drivers (72). These drivers are configured to recognize 
extensbns based on the devbe driver entry points (74). 
For example, rf a static NVRAM read/write device driver 
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entry point is called, the driver first checks to see if there 
are any registered extensions for that entry point and, if 
so, calls the registered extension. The extension can ex- 
amine the offset of the NVRAM request and determine 
if it was in the NVRAM device that it controls. If so, the s 
extension would service the request, but If not, it then 
would retum control to the static driver, which would call 
the next registered extension or, if appropriate, handle 
the request itself. After the operating system has been 
loaded and any driver extensions have been registered, 
regular user programs are executed (76). Then, when 
any application sends a function call to a static device 
driver with a registered extension, the static driver re- 
routes the call to the extension (78). In this manner, reg- 
istration allows the extension to override a particular 
functionality of, or add new functbnality to, the static 
driver. 

In one specific implementation of the present inven- 
tion, an AIX operating system is modified to provide a 
machine device driver (/dev/nvram) which is a static de- 20 
vice driver providing the base functionality required be- 
fore rt is possible to dynamically load further support. 
However, via a special extension file registered with the 
machine device driver, additional functions are provided 
that are nriachine-specific. This approach allows com- 2S 
mon static functions to remain in the base operating sys- 
tem while nr)oving machine-specific functions to appro- 
priate kemel extensk>ns to be dynamically loaded and 
registered with the machine device driver at run-time. 

Unlike dynamically baded drivers, registered driver 30 
extensions 64 are not usually a complete driver, i.e., the 
extension usually modifies only a portkxi of the driver 
functtonaltty. A registered extension could, however, 
completely replace all f unctk)nality for a given static driv- 
er, or two or more registered extensions coukj be used 3S 
to overrkje all base functbnality. Those skilled in the art 
will appreciate that an operating system constructed in 
accordance with the present inventbn can still have dy- 
nambally baded drivers (not shown in Figure 4) in ad- 
ditbn to registered driver extensbns 64. 40 



Claims 

1 . A method for providing control of a devbe (1 4) in a ^ 
computer system (10) having memory (18). com- 
prising the step of: 

loading (72) a static device driver (56) into the 
menrwry (1 8) of the computer system, the static 50 
device driver having means for providing a plu- 
rality of functions used to control the device; the 
method being characterised by the further step 
of: 

55 

dynambally extending (74) the static device 
driver using a driver extension (64). 



2. A method as claimed in Claim 1 wherein the statb 
devbe driver is dynamically extended in response 
to a function call from a user application. 

3. A method as claimed in Claim 1 or Claim 2 wherein 
the statb device driver is loaded as part of the fur- 
ther step (72) of bading an operating system on the 
computer system. 

4. A method as claimed in any preceding claim where- 
in: 

the computer system is a UNIX-type worksta- 
tion having a kemel (54) residing in the memo- 
ry: 

the static device driver is baded in the kemel; 
and 

the static device driver is dynamically extended 
by provbing at least one entry point for the driv- 
er extensbn. 

5. A method as claimed in any preceding claim where- 
in the static device driver is dynamically extended 
by providing (74) a registratbn in the static device 
driver for the driver extension. 

6. A method as claimed in any preceding claim where- 
in the driver extension modifies at least one of the 
plurality of functions of the static device driver. 

7. A method as claimed in any preceding claim where- 
in the driver extension provbes a new function for 
controlling the device. 

8. A method as claimed in any preceding claim where- 
in the driver extension is also loaded in the mennory 
of the computer. 

9. A method as claimed in Claim 6 wherein said at 
least one functbn is an input/output functbn. 

10. A method as claimed in Claim 6 wherein the static 
devbe driver is dynamically extended by registering 
the driver extension with at least one function. 

11. A computer system comprising: 

a hardware device (52); 

memory means (18) storing a statb device driv- 
er (56) used to control said hardware device; 

processor means (12) for carrying out instruc- 
tions from sab static devbe driver to control 
sab hardware devbe; characterised in that the 
system further comprises: 
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a device driver extension (64) registered with 
said static device driver such that a function call 
issued to said hardware device is rerouted by 
said static device driver to said device driver ex- 
tension, s 

12. A computer system as claimed in Claim 11 wherein: 

said static device driver provides a plurality of 
functions for controlling said hardware device; io 
and 

said static device driver is arranged to re-route 
a function call to said device driver extension 
for one or more of said functions. is 

1 3. A computer system as claimed in Claim 1 1 or Claim 
12 wherein: 

the computer system is a UNIX-type worksta- 20 
tion having a kernel (54) residing in said mem- 
ory means; 

said static device driver is loaded in sakj kemel; 
and 2S 

said statk: device driver is arranged to re-route 
said function call by providing an entry point for 
said device driver extensbn. 

30 

14. A computer system as claimed in Claim 11 wherein 
said device driver extension provides a new func- 
tion for controlling the device. 

1 5. A computer system as claimed in Claim 1 3 wherein 35 
the kemel includes a hardware control unit (58). and 
said device driver extension interfaces directly with 
said hardware control unit. 

40 
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